Networks have transformed the way people do computing. Someone with access to a personal computer or workstation can connect to the Internet and communicate with systems and people all over the world. The World Wide Web (WWW or Web) is a way of using the Internet that provides the user with access via linked documents to a wealth of information distributed throughout the globe. The WWW also allows users to execute programs running on remote servers. This capability enables users to obtain the results from programs which the user cannot run locally due to hardware and/or software limitations. It is also possible to download and run programs stored remotely on the World Wide Web. This has the potential to greatly increase the amount of software which is available to a computer connected to the World Wide Web.
Network Protocols
Network protocols provide standard methods for machines to communicate with one another. The protocols indicate how data should be formatted for receipt and transmission across networks. Heterogeneous machines can communicate seamlessly over a network via standard protocols. Examples of standard Internet protocols include: HTTP, see, e.g., "Hypertext Transfer Protocol--HTTP/1.0", http://www.ics.uci.edu/pub/ietf/http/draft-ietf-http-v10-spec-03.html, by T. Berners-Lee, R. Fielding, and H. Frystyk, Sep. 4, 1995; SMTP, see, e.g, "Simple Mail Transfer Protocol". RFC 821, J. B. Postel, Information Sciences Institute, USC, August 1982, http://ds.internic.net/std/std10.txt.; NNTP, see, e.g., "Network News Transfer Protocol: A Proposed Standard for the Stream-Based Transmission of News", RFC 977, B. Kantor and P. Lapsley, UC San Diego and UC Berkeley, February 1986, http://ds.internic.net/rfc/rfc977.txt.; FTP, see e.g., J. Postel and J. K. Reynolds. "File Transfer Protocol (FTP)", RFC 959, Information Sciences Institute, USC, October 1985, http://ds.internic.net/std/std9.txt.; Gopher, see, e.g., F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, D. Torrey, and B. Alberti. "The Internet Gopher Protocol: A distributed document search and retrieval protocol", RFC 1436, University of Minnesota, March 1993, http://ds.internic.net/rfc/rfc1436.txt.; and WAIS, see, e.g., F. Davis, B. Kahle, H. Morris, J. Salem, T. Shen, R. Wang, J. Sui, and M. Grinbaum. "WAIS Interface Protocol Prototype Functional Specification" (v 1.5), Thinking Machines Corporation, April 1990.
The client-server model constitutes one of the dominant paradigms in network programming, see, e.g., W. R. Stevens, "Unix Network Programming", Prentice Hall PTR, Englewood Cliffs, N.J., 1990; and D. E. Comer, "Internetworking with TCP/IP" vol 1., Prentice Hall, Englewood Cliffs, N.J., 1991 which is hereby incorporated by reference in its entirety. A server program offers a service which can be accessed by multiple users over the network. A program becomes a client when it sends a message to a server and waits for a response from the server. The client process, which is typically optimized for user interaction, uses the requested service without having to know any of the detailed workings of the requested service or server. On the World Wide Web, "browsers" constitute client programs while the programs sending back information to the browser constitute server programs.
A client and server may communicate either synchronously or asynchronously. In a synchronous communication, a client waits for a response from a server before issuing the next request. In an asynchronous communication, the client may issue a request to a server before one or more responses from previous requests to the server have been received.
Many network protocols between a client and server are stateless. This means that every request from a client to a server is treated independently. The server has no record of previous connections. HTTP is an example of a stateless protocol. Two advantages of using stateless protocols are efficiency and simplicity. However, there are situations where it is desirable for maintaining state information during communications between the client and server. For these types of interactions, the statelessness of protocols can present problems.
The HTTP Protocol and the World Wide Web
The most compelling application of the present invention is for browsing the World Wide Web via the HTTP protocol, see, e.g., "Hypertext Transfer Protocol--HTTP/1.0", http://www.ics.uci.edu/pub/ietf/http/draft-ietf-http-v10-spec-03.html, by T. Berners-Lee, R. Fielding, and H. Frystyk, Sep. 4, 1995, which is hereby incorporated by reference in its entirety. Those skilled in the art will understand, however, that the present invention is not limited to HTTP. The relevant aspects of the Web and the limitations imposed by the statelessness of protocols, such as HTTP, will now be discussed.
The World Wide Web consists of multiple servers networked together. Clients typically communicate with servers using a standard browser such as are sold under the trademarks "NETSCAPE NAVIGATOR" by Netscape, "MOSAIC" from NCSA, or "WEB EXPLORER" by IBM. The most common method of communicating between clients and servers is via the HTTP protocol. HTTP allows the client to obtain data from the server either by requesting a file or invoking a program known as a Common Gateway Interface (CGI) program which executes on the server. CGI programming is well known in the art. See, e.g.,"HTML and CGI Unleashed" by John December and Mark Ginsburg, Sams.net Publishing, Indianapolis, Ind. (1995). The server then sends file or the output from the CGI program to the client. Servers typically restrict the files and programs which a client has the ability to access.
The server sends information to the client using the HyperText Markup Language (HTML), see, e.g., "The HTML Sourcebook" by Ian S. Graham, John Wiley & Sons, Inc., New York, 1995, which is hereby incorporated by reference in its entirety. HTML documents consist of conventional ASCII text in which the information to be displayed is interspersed with HTML markup tags. These tags are surrounded by greater than and less than signs (&lt; . . . &gt;) and instruct the browser how to interpret different parts of documents. Browsers use Uniform Resource Locators (URLs) to uniquely identify or address information on the Internet. Browsers read HTML documents corresponding to the URLs and display them by following the instructions stored in the markup tags.
The HTML code sequence below (Table 1) shows the HTML text corresponding to the Web home page of the IBM T. J. Watson Research Center on Jun. 3, 1996. This Web page corresponds to the URL "http://www.watson.ibm.com/". The corresponding output that would be displayed on a standard browser accessing this page is shown in FIG. 1.
TABLE 1 __________________________________________________________________________ The HTML source code corresponding to the IBM T. J Watson Research Center home page. __________________________________________________________________________ &lt;HTML&gt;&lt;HEAD&gt; &lt;TITLE&gt;IBM T. J. Watson Research Center home page&lt;/TITLE&gt; &lt;meta name="owner" content="calyson@watson.ibm.com"&gt; &lt;meta name="review" content="19960202"&gt; &lt;/HEAD&gt; &lt;BODY&gt; &lt;IMG SRC="/watson/mast.gif" alt="Research" &gt; &lt;p&gt; &lt;hl&gt;IBM T.J. Watson Research Center&lt;/hl&gt; &lt;p&gt; &lt;IMG SRC="/watson/night.gif" &gt; &lt;IMG SRC="/watson/haw2.gif" &gt; &lt;br&gt; &lt;i&gt;T.J. Watson Research Center: Yorktown (left) and Hawthorne.&lt;/i&gt; &lt;p&gt; &lt;ul&gt; &lt;IMG align=middle SRC="/watson/bullet.gif" &gt;&lt;A HREF="/watwel.html" &gt; Welcome|&lt;/a&gt; &lt;br&gt; &lt;IMG align=middle SRC="/watson/bullet.gif" &gt;&lt;A HREF="/leo" &gt;Local Education Outreach &lt;/a&gt; &lt;br&gt; &lt;IMG align=middle SRC="/watson/bullet.gif" &gt;&lt;A HREF="/menu.html" &gt; Visitor info and local site directions &lt;/a&gt; &lt;br&gt; &lt;IMG align=middle SRC="/watson/bullet.gif" &gt;&lt;A HREF="/lodging.html" &gt; Local hotels&lt;/a&gt; &lt;br&gt; &lt;IMG align=middle SRC="/watson/bullet.gif" &gt;&lt;A href="http://www.ibm.com"&gt; IBM home - &lt;A href="http://www.research.ibm.com/"&gt; IBM Research home page&lt;/a&gt; &lt;br&gt; &lt;ul&gt; &lt;p&gt; &lt;hr&gt; &lt;A HREF="/watson/mail.html" &gt;&lt;IMG align=middle SRC="/research/images/mail.gif" &gt;&lt;/a&gt; &lt;b&gt;Click on icon to send your comments.&lt;/b&gt; &lt;p&gt; Or, contact &lt;i&gt;webmaster@watson.ibm.com&lt;/i&gt; &lt;p&gt; &lt;hr&gt; &lt;Address&gt;&lt;homepage@watson.ibm.com&gt;&lt;/address&gt; &lt;b&gt; &lt;A href="http://www.ibm.com/"&gt;IBM home page&lt;/a&gt;.vertline. &lt;A href="http://www.ibm.com/Orders/"&gt;Order&lt;/a&gt;.vertline. &lt;A href="http://www.austin.ibm.com/search/"&gt;Search&lt;/a&gt;.vertline. &lt;A href="http://www.ibm.com/Assist/"&gt;Contact IBM&lt;/a&gt;.vertline. &lt;A href="http://www.ibm.com/Finding/"&gt;Help&lt;/a&gt;.vertline. &lt;A href="http://www.ibm.com/copyright.html"&gt;(C)&lt;/a&gt;.vertline. &lt;A href="http://www.ibm.com/trademarks.html"&gt;(TM)&lt;/a&gt; ! &lt;/b&gt; &lt;/BODY&gt; &lt;/HTML&gt; __________________________________________________________________________
Many Web browsers allow users to view the HTML source code of any document being viewed. The HTML text in Table 1 is stored in a file accessible to a Web server at the IBM T. J. Watson Research Center. When this Web server receives a request for the URL "http://www.watson.ibm.com/", it sends the appropriate file to the client's browser. The client's browser will then read and display the HTML file. (Table 1 contains a number of relative links. The hypertext links and image files are only valid if the file is stored in a specific directory. If, for example the "night.gif" file in Table 1 is stored at an arbitrary location, the hypertext links will be invalid and the associated images will not appear.)
The line in Table 1 reading "Visitor info and local site directions" is an example of a hypertext link (also called a hyperlink). The corresponding output as it would be displayed by a standard browser is depicted in FIG. 1. When the user clicks on this link as depicted in FIG. 1 when displayed by the browser, a new HTML file, "menu.html", is fetched from the server and displayed by the browser. Hypertext links to documents on both local and remote servers can be placed in an HTML file. The ability to incorporate hyperlinks within an HTML file to link documents on servers all over the world is one of the key features of the World Wide Web. In other words, a Web browser can be used to access information from servers all over the world by simply pointing and clicking on hypertext links.
Recall that Hypertext links are examples of "continuations" in client-server communication. A continuation is a new request which a client may send to a server. Whenever a client requests something from a server, the server may include one or more continuations in its response. The continuations could represent any valid requests. However, useful continuations are generally logically related to the original request. A good set of continuations makes it easy for a client to communicate synchronously with a server. After each request, the server responds with a set of continuations. The client chooses one of the continuations for the next request. A "conversation" is a sequence of communications between a client and server in which the server responds to each request with a set of continuations and the client always picks the next request from the set of continuations.
On the Web, hypertext links represent continuations and a client engages in a conversation whenever it follows hypertext links. A conversation is interrupted whenever the client obtains a new page by explicitly requesting a new URL instead of following hypertext links. It is possible to continue an interrupted conversation if a page corresponding to the interrupted conversation is still available to the client, e.g., in the browser cache or in disk memory. If so, the conversation may be continued by reloading the page and continuing to follow hyperlinks. A client may communicate with multiple servers during the same conversation.
More formally, a series of HTML pages p1, p2, . . . , pn constitutes a conversation if:
1. p1, p2, . . . , pn were all viewed by a client, and PA0 2. for all i, such that 1&lt;i&lt;=n, page pi was obtained by following a hypertext link on page pi-1. PA0 1. Initially visits a page pi where 1&lt;=i&lt;n, PA0 2. Views other pages either by following hyperlinks or explicitly accessing URL's, and PA0 3. Returns to page pi by reloading pi from memory (presuming that pi is still available).
In an uninterrupted conversation, the client simply follows n-1 hypertext links to get from page p1 to pn without ever "backtracking". In an interrupted conversation, the client backtracks at least once. By backtracking, we mean that the client:
All requests for URL's are stateless. Even if a client requests a page multiple times, the server doesn't maintain any history or knowledge of previous connections. When a client requests an HTML file, there is no way for the client to communicate additional information with the request. Thus, a need exists in the Web environment to preserve state information throughout a conversation while a client is browsing HTML files. The present invention addresses such a need.
For example, consider a server which is handling business transactions. In order to function properly, the server needs state information such as the client's user ID and the transaction number corresponding to the current transaction number. Thus, there is a need to preserve this information while the client is browsing HTML files by following hyperlinks in a conversation. The present invention addresses such a need.
Current Methods for Handling State on the Web
One current method for handling state on the Web involves the use of CGI programs. A client can invoke a CCI program by passing arguments to it. For example, the command, http://tranman.watson.ibm.com/cgi-bin/get-args?var1=7 & var2=10 invokes a CGI program passing the variables var1=7 and var2=10. It is cumbersome to expect the client to follow the exact syntax for passing variables to CGI programs. A more user-friendly method is to allow the user to input arguments via an HTML "form". An example of an HTML form as displayed by a Web browser is shown in FIG. 2. The user fills in the appropriate fields and sends the information to the server by clicking on the send button. The values typed in by the user are passed along as arguments to a CGI script. "Forms" provide a convenient interface for passing arguments to CGI programs. The client does not need to know the details of the CGI program being invoked or the format of the arguments expected by the program.
Forms allow the client to pass state variables to the server. Servers can also use forms to pass variables to the client. Forms may include hidden variables which are not displayed to clients and which are passed back to a server when the client submits the form. Web servers typically preserve state by passing state variables as hidden variables within forms. When the client submits the form, the server receiving the form can obtain the state variables from the hidden fields.
For example, suppose that a business transaction server is communicating with a client. The transaction server needs to obtain a client user ID and a session ID for the remainder of the conversation with the client. The server can obtain the client's user ID from a form submitted by the client. The form invokes a CGI program which then generates a session ID. Each subsequent response from the server is a form. The form is generated dynamically and contains the user and session ID's embedded as hidden variables. Clients respond by completing and submitting the forms generated by the server.
FIG. 3 depicts an example of a current method for preserving state using HTML forms. As depicted, the server 410 embeds state variables in hidden arguments to HTML forms 420 which are generated dynamically. The state variables 425 are passed back and forth between the client 450 and the server 410. Using forms, the client 450 and the server 410 pass the state information 425 back and forth. The server 410 passes the state information to the client by creating HTML forms 420 on the fly and embedding the state variables 425 in hidden fields. The client 450 passes the state information 425 back to the server by completing and submitting the forms 420' generated by the server 410.
Limitations of the Current Technology for Handling State
The problem with the approach just outlined is that it seriously limits the types of interactions between a client and a server during a conversation. The server 410 must always respond to the client 450 with a dynamically generated HTML form 420 containing hidden variables 425. There is no way to preserve state while the client browses HTML files. For example, suppose that the client wishes to browse a catalog in the middle of the session. The catalog consists of HTML files. There is no way to allow the client to browse (different HTML files in) the catalog without losing the state information using current technology. If the server allows the client to continue a conversation by viewing the catalog, the state information will be lost as soon as the client accesses an HTML file from the catalog.
Thus, there is a need for a system and method that allows the client to browse the catalog, i.e., access different HTML files while preserving the state information. The present invention addresses such a need, regardless of whether the HTML files constituting the catalog reside on different servers.
The limitations of the current technology for preserving state have been noted by others, see, e.g., "Persistent Client State HTTP Cookies", Netscape Communications Corporation, 1996, http://home.netscape.com/newsref/std/cookie.sub.-- spec.html; see also, "Proposed HTTP State-Info Mechanism", D. M Kristol, AT&T Bell Laboratories, Sep. 22, 1995, http://www.research.att.com/.about.dmk/session01.txt.; and M. Cutler and D. Hall, "August 1995 Web Watch", http://www.netgen.com/corpinfo/press/webwtchv6n8.html. Unlike the solution suggested by Kristol which would modify the HTTP protocol to preserve state, the present invention preserves state without requiring changes to the underlying protocol.
Another solution, by Netscape Communications has been to add a feature called Cookies to their browsers; see "Persistent Client State HTTP Cookies", Netscape Communications Corporation, 1996, http://home.netscape.com/newsref/std/cookie.sub.-- spec.html. Here, a server can satisfy an HTTP request by appending a state object known as a cookie to its response. The cookie contains a description of the range of URL's for which the state is valid. The cookie is stored by the Netscape browser running on the client. Any future HTTP requests made by the client to one of the URL's specified in the cookie will include a transmittal of the state object stored in the cookie from the client back to the server.
There are a number of drawbacks to this approach. The server application which wishes to preserve state must provide a list of all URL's which might make use of the state. This is cumbersome and may sometimes be impossible. Cookies also lack a method for correlating state information with specific conversations. For example, suppose a browser accesses the same URL in two separate conversations. During the first conversation, state information exists at the time the URL is accessed and is passed to the server via a cookie. During the second conversation, no state information exists at the time the URL is accessed. However, the old cookie still exists and the old state is still passed back to the server. This would confuse the server into believing that the old state information still applies to the new conversation. Another problem is that cookies are not a standard feature and will only work with servers and browsers which support Netscape's protocol.
Thus, there is a need for a method and system for preserving state in a stateless protocol which is not limited to a list of URL's which need to make use of the state information and where state information is correlated with specific conversations to avoid the problem of passing outdated state information to a server. Moreover, there is a need for a system of preserving state in a protocol as HTTP that works with any browser supporting the HTTP protocol and doesn't require specialized nonstandard features on the client or server.